Subject: Recent CAPEX comments

From: [email-masked] (Paul Brittain)
Date: Fri, 2 Sep 94 12:39:39 BST

Frank

Some comments on your replies to Peter's last capex mail.  I have edited out
the points where the two of you already agree.

Yours

Paul Brittain
Data Connection.

Referenced Mail:
================

>>
>> - For CV 88 "Exclusivity", paragraph 2 of the description seems to
>>   state that if you have a MAC addr or NB name list but do not have
>>   CV 88, the receiver should assume you had a CV 88 with the indicator
>>   value of 0x00 ("not exclusive").  I don't like this sort of IMPLIED
>>   stuff, and would very much prefer we have the following rules:
>>      - if you include a MAC addr list CV, the MAC addr exclusivity
>>        list CV must also be included
>>      - if you include a NB name list CV, the NB name exclusivity
>>        list CV must also be included
>>   The converse of these rules is not true, i.e., one could have an
>>   exclusivity CV without the corresponding list CV.  This is currently
>>   discussed in paragraph 3, which now needs a little rework because we
>>   have two exclusivity CVs.  I would like to suggest the following
>>   wording to replace paragraph 3:
>>
>>     For the MAC Address List Exclusivity CV:
>>        A node may specify that it supports no local MAC addresses by
>>        including in its capabilities the MAC Address List Exclusivity
>>        CV (with byte 2 == X'01'), and not including any instances of
>>        the MAC Address List CV.
>>
>>     For the NetBIOS Name List Exclusivity CV:
>>        A node may specify that it supports no local NetBIOS names by
>>        including in its capabilities the NetBIOS Name List Exclusivity
>>        CV (with byte 2 == X'01'), and not including any instances of
>>        the NetBIOS Name List CV.
>
>I believe we discussed this at an AIW and the group was Ok with
>non-exclusive as the default. I think it is too late to change it
>for release 1.
>
I agree that the last AIW chose non-exclusive as the default.  However I also
think that we should use Peter's suggested replacement for para 3 as it is
clearer and does not require any change to the non-exclusive default.

>>
>> - In CV 89 "MAC Address List", the current text reads "MAC addresses
>>   and masks are in canonical in this control vector".  I think this
>>   should be changed to "MAC addresses and masks are in non-canonical
>>   format in this control vector", per our agreement at the AIW.
>
>My notes from the last AIW say that we decided that MAC addresses and
>masks are canonical in the CapEx and non-canonical in the protocol.
>I actually prefer it your way. Can someone help us out here?
>
I believe it should be non-canonical in cap-ex too, and it is certainly more
consistent that way.

>>
>> - In CV 8A "NetBIOS Name List", I think we should explicitly state that
>>   '*' is permitted only at the end of a name.  The text implies it but
>>   should probably state it flat out.  Also, I think we should beef up
>>   the language about names with trailing blanks/nulls to also treat
>>   the case of short names which do not end with '*'.  How about this
>>   for a new 3rd paragraph:
>>
>>      NetBIOS names which have fewer than 16 bytes and which do not
>>      end with '*' are not assumed to have a trailing '*';  the
>>      "wildcard" character must be explicit.  They are also not assumed
>>      to have any particular trailing pad character, and cannot match
>>      names with a different length.  Blanks and nulls at the end of
>>      end of names in this CV are ignored, and should be ignored
>>      in names being compared to these.
>>
>>   (not very well worded, maybe someone else can improve on it ....)
>
>Would it be acceptable to you if I add your first sentence to what is
>already there like so...
>
>    All blanks or nulls at the end of NetBIOS names in this control vector
>    are ignored. NetBIOS names which have fewer than 16 bytes and which do
>    not end with '*' are not assumed to have a trailing '*';  the "wildcard"
>    character must be explicit.
>
I think Peter's point about how comparisons are made should also be included
thus:

     All blanks or nulls at the end of NetBIOS names in this control vector
     are ignored, as are trailing blanks and nulls in any NetBIOS names to
     which this data is compared. NetBIOS names which have fewer than 16 bytes
     and which do not end with '*' are not assumed to have a trailing '*';  the
     "wildcard" character must be explicit.

As a final additional point, how about reordering the subsections so that the
control vectors are described in detail in numerical order?  I think it is just
the SAP Support List CV that is out of place.

---

From: Frank Bordonaro <[email-masked]>
Date: Fri, 2 Sep 94 8:46:07 PDT

Paul,

Thanks for the comments.

Point #1: Yes, Peter's 3rd paragraph was added after his suggestion even 
though I didn't mention it in my reply. 

Point #2: Thanks for the feedback. So far all respondants have said that
it makes more sense to use non-canonical MACs in the CapEx (regardless of
what we thought we heard at AIW #5), so I think it is now very clear that
we should go this route. Unless someone presents an good argument for
canonical MACs in CapEx, the next draft will reflect using non-canonical MACs.

Point #3: I will re-order the subsections. I'll have to move the
Supported SAP List CV (0x86) and the MAC Address Exclusivity CV (0x85).
I think there is a minor downside to this that I just want to mention.
Now the MAC Address Exclusivity CV descrciption will not be adjacent to that
of the NetBIOS Name Exclusivity CV. I was trying to keep the two close together
for continuity/readability. This would have been nice, but order seems to be 
more important. Let me know if this makes a difference to you.

Regards,
Frank Bordonaro
cisco Systems, Inc.